FIG. 1 schematically shows a conventional graphics system, which may be generally represented as having four functional stages. In particular, the system in FIG. 1 has a host application 10 that produces generalized function calls (e.g., complying with either of the OPENGL or DIRECT3D graphics libraries) for processing by downstream graphics hardware 12. Graphics hardware 12, however, cannot read generalized function calls. Accordingly, an intervening graphics driver 14 translates the generalized function calls to specifically formatted calls (referred to as “hardware specific calls”) that can be processed by the graphics hardware 12. The graphics driver 14 then forwards the hardware specific calls to the graphics hardware 12, which generates image data for display by a display device 16 (e.g., a cathode ray tube or liquid crystal display).
The four functional stages of the graphics system shown in FIG. 1 typically communicate across some kind of hardwired connection, such as a bus or other type of special-purpose connection (i.e., schematically shown by the arrows). For example, all four stages may be within a single personal computer. To more efficiently process graphical data, however, some systems distribute the various stages across different computers.
One distributed graphics processing implementation has a host application 10 executing on a local computer, while the remaining stages execute on a virtually connected remote computer. One problem with this implementation, however, is that it requires additional overhead. Specifically, because they refer to data in local memory (which has no meaning to a remote computer), function calls generated by the host application 10 must be translated into a format that can be transferred across a network and understood by a remote computer. Software designers therefore have developed protocols that convert local function calls into transferable, remotely understandable entities, such as specific assigned values. For example, the “DRAW” command could be assigned the value of binary 0001, which subsequently is transferred across the Internet to a remote computer. This conversion process is known as “encoding” the function calls.
Of course, the remote computer must have the functionality to convert assigned values from this protocol back into a function call that can be processed by its local driver 14 (referred to as “decoding”). Accordingly, a decoder on the remote computer converts each assigned value back into a function call, which then can be used by the driver 14 to continue graphic processing.
Despite efficiencies gained by using a distributed computing solution, this implementation creates new inefficiencies. Among others, requiring a separate encoder and decoder necessarily increases both transmission latency and the number of process steps required to ultimately generate a graphical image. Such inefficiencies can negate or significantly mitigate the efficiencies of a distributed computing solution. In addition, because the host application 10 is not configured to optimize its output based upon the graphics hardware 12, the encoder simply encodes the graphics commands on the fly without making any optimizations.